The present exemplary embodiments relate generally to e-commerce. They find particular application in conjunction with payment brand selection and/or consumer authentication, to conduct a commercial transaction over a communications network (e.g., the Internet), and will be described with particular reference thereto. However, it is to be appreciated that the present exemplary embodiments are also amenable to other like applications.
By way of background, Internet commerce, or e-commerce as it is otherwise known, relates to the buying and selling of products and/or services between consumers and merchants over the Internet or other like transactional exchanges of information. The convenience of shopping over the Internet has sparked considerable interest in e-commerce on behalf of both consumers and merchants. Internet sales, or like transactions, have been typically carried out using standard credit cards, for example, from Visa®, MasterCard®, Discover®, American Express®, or the like, or standard debit cards, such as check cards or automated teller machine (ATM) cards which directly access funds from an associated deposit account or other bank account.
FIG. 1 illustrates one example of an authorization process for an e-commerce transaction. When a consumer 102 seeks to purchase a product and/or service from a merchant 104, they complete a checkout process in which they typically provide the merchant 104 with payment information, or at least enough information to identify and/or locate payment information. Payment information typically identifies a payment instrument, such as a credit card, associated with a payment brand. Upon receiving the payment information, the merchant 104 authorizes the transfer of funds using an authorization supply chain 106. The authorization supply chain 106 typically includes an optional payment gateway 108, a payment processor 110 (e.g., the merchant's financial institution or acquiring bank), a payment brand network 112, an issuing bank 114, and the like. In certain embodiments, the merchant 104 connects directly with the payment processor 110, whereby the payment gateway 108 is optional.
While widely used for more traditional face-to-face transactions, use of these standard cards in connection with e-commerce presents certain difficulties, including difficulties concerning authentication or positive identification of the cardholder. For example, maintaining consumer confidence in security has become difficult with increased reports of fraud. The resulting apprehension is also fueled by consumer uncertainty of the reputation and/or integrity of a merchant with whom the consumer is dealing. Questionable security of the consumer's card information or other personal information (e.g., address, card number, phone number, and the like) typically submitted along with a traditional e-commerce transaction serves to increase apprehension even more. Additionally, cardholders, merchants and financial institutions are all concerned about safeguarding against fraudulent or otherwise unauthorized transactions.
Accordingly, various payment brand networks have implemented programs (or initiatives) aimed at safeguarding against fraud. For example, Visa® and MasterCard® both support authentication programs in which the bank or financial institution issuing the card (i.e., the issuing bank) authenticates a cardholder. FIG. 2 illustrates one such exemplary authentication program. As shown, a consumer 202 (e.g., employing a suitable web browser or the like) attempts to purchase products and/or services (e.g., over the Internet) from a merchant 204. As is known in the art, the illustrated authorization supply chain 206 includes an optional payment gateway 208, a payment processor 210, a payment brand network 212, and an issuing bank 214.
At a point of checkout, the consumer 202 selects an appropriate payment method based on the authentication programs supported by the merchant 204. At this point, the consumer 202 fills out an on-line checkout form including a payment instrument, a card number, an expiration date, etc. Based on the payment information, the merchant 204, via a plug-in 216 installed on their servers, passes a verify enrollment request (VEReq) message to a directory server 218 suitably operated by the payment brand network 212. The directory server 218 includes a database associating participating merchants with their payment processor and a database associating card number ranges with locations or addresses (e.g., universal resource locator (URL) addresses) of issuing banks access control servers (ACSs). The VEReq message is a request to verify the enrollment of the card in the authentication program, and it contains the card number provided by the consumer 202.
Based on the card number range stored within the directory server 218, the VEReq message is sent to an ACS or attempts server 220. If the consumer and/or the issuing bank do not participate in a payment program, the VEReq message is sent to an attempts server typically operated by the payment brand network 212. Otherwise, the VEReq message is sent to the appropriate URL address for the issuing bank's ACS server. In either case, a response (i.e., a verify enrollment response (VERes)) to the VEReq message is returned to the merchant 204 via the directory server 218. That is to say, the ACS or attempts server 220 responds with a VERes message to the directory server 238, which is then passed back to the plug-in 216. Where the ACS or attempts server 220 is an ACS, the enrollment status of the card is also verified.
Based on the VERes message (i.e., if positive), the plug-in 216 redirects the consumer's browser to the ACS or attempts server 220 by passing it a payer authentication request (PAReq) message generated by the plug-in 216. The consumer 202 then completes an authentication process or attempts directly with the ACS or attempts server 220. The ACS or attempts server 220 authenticates the consumer 202, if applicable, and responds to the merchant 204 with a payer authentication response (PARes) message, including a digital signature. The plug-in 206 validates the digital signature of the PARes and extracts the authentication status and other specified data that is to be used by the merchant 204 during the payment authorization process carried out via the authorization supply chain 206. For example, the merchant 204 sends an authorization and/or sale transaction to their payment gateway 208 along with the data elements received from the PARes. The payment gateway 208 routes the data to the payment processor 210 based on the payment processor's specification. The payment processor 210 then sends the data via the appropriate payment brand network 212 to the issuing bank 214 for settlement.
With industry momentum swinging in the direction of authentication of consumers, more and more merchants are implementing authenticated payment programs, such as the aforementioned example, for the first time. With these initial implementations, merchants run the risk of introducing an authenticated payment program in a way that could disrupt their current checkout process. Further, merchants are responsible for remaining current with program protocols that can change periodically. That is to say, as the authentication protocols are updated and/or changed by the respective payment brand networks, the merchants are responsible for updating and/or changing their plug-ins to reflect those updates and/or changes being mandated by the payment brand networks.
Even more, when using authentication programs, the payment brand networks often ensure participating merchants that fraudulent transactions and other charge backs, as they are known in the art, will not be the merchants' responsibility provided the specified protocols have been followed. However, there are considerable burdens placed upon the merchants to participate in the authentication programs. For example, typical installation of the merchant plug-in can be overly burdensome using up resources (e.g., computing power, memory, data storage capacity, etc.) the merchant would otherwise prefer to devote to other tasks. Often, the plug-in can be extremely large and/or cumbersome to implement on the merchant's server. Moreover, for a merchant that participates in a plurality of such authentication programs for multiple payment brand networks, the burden can be that much more (i.e., requiring a separate plug-in for each individual authentication program they wish to support), especially considering that each payment brand network may have its own particular protocols, data fields that are employed in the respective messages, specific data format requirements, etc.
To address some of these concerns, a universal merchant platform (UMP), shown in FIG. 3, may be employed. For detailed a detailed discussion regarding the universal merchant platform, refer, for example, to U.S. Pat. No. 7,051,002 entitled “Universal Merchant Platform for Payment Authentication” and U.S. Patent Publication No. 2006/0282382 entitled “Universal Merchant Platform for Payment Authentication,” the disclosures of which are both incorporated herein by reference.
Generally, the UMP serves as a centralized merchant processing system for authenticated payments, allowing a merchant to securely and easily accommodate authentication of consumers in accordance with a variety of authentication programs implemented by payment brand networks, and to process electronic transactions through any payment network using a single platform. It also enables merchants to process these payments, regardless of which payment network they are to be routed through, with a single implementation. Moreover, it allows them or a funding source to use the established underlying payment processing infrastructure to process their credit and/or debit payment instruments at participating merchant sites.
While the UMP addresses some of the abovenoted concerns, there is still room for improvement. For example, known embodiments of the UMP are a “one size fits all solutions” in the sense that a merchant either employs an authenticated payment program or does not. Therefore, merchants run the risk of introducing an authenticated payment program in a way that could disrupt their current checkout process, even when employing known embodiments of the UMP.
The present invention contemplates a new and improved system and/or method which overcomes the above-referenced problems and others.